The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Virtual private network (VPN) technology is now widely used to provide secure communication of information over public or non-trusted networks. In a typical VPN arrangement, an end user is associated with an end station device, such as a workstation or personal computer, which executes VPN client software. The end station establishes a connection through a non-trusted network, such as the public Internet, to a gateway or other network node associated with a secure network of a business enterprise or other entity. The end station and network node negotiate encryption keys, essentially creating an encrypted “tunnel” connection through the un-trusted network. For example, the tunnel may be created using Secure Sockets Layer (SSL). The end station and network node then communicate encrypted information over the un-trusted network, and the encrypted information is decrypted at the endpoints.
In this arrangement, the end user can securely obtain information from private network resources through the VPN tunnel, even though one or more intermediate networks are untrusted. Typical VPN users are enterprise workers who telecommute or telework.
Web pages may be among the private network resources that an end user can obtain. These web pages are served by web server applications using the Hypertext Transfer Protocol (HTTP). There may be multiple web servers within a VPN.
Each web server, and each web page served by a web server, may be associated with a separate Uniform Resource Locator (URL). Because the web servers are located within a VPN, the web servers' associated URLs are not recognized outside of the VPN. Domain name servers that are outside of the VPN are unable to resolve the URLs of web servers that are inside of the VPN. Thus, if the URL of a web page that is served by such a web server is entered into the “address” field of a web browser application, then the web browser indicates that the resource corresponding to the URL cannot be located.
Therefore, to communicate with a web server that is located within a VPN, a web browser first establishes a tunnel with the VPN gateway as discussed above. In certain implementations, to initiate the establishment of the tunnel, the web browser's user enters the VPN gateway's URL into the web browser's “address” field. The web browser sends an HTTP request to the VPN gateway. The VPN gateway responds by initiating an authentication process with the web browser's user.
Provided that the VPN gateway is able to authenticate the web browser's user, the VPN gateway sends a form, such as a Hypertext Markup Language (HTML) form within a “portal page,” to the web browser. The form includes a field in which the web browser's user can enter a URL of a web page that is served by a web server within the VPN. The user enters the URL of the desired web page into the field and submits the contents of the form's fields in an HTTP response to the VPN gateway.
The VPN gateway receives the HTTP response. The VPN gateway generates an HTTP proxy request, which requests the web page at the URL that is indicated in the form field. The VPN gateway sends the HTTP proxy request, through the VPN, to the web server that is associated with the URL.
The web server receives the HTTP proxy request and serves the web page to the VPN gateway in an HTTP response. The VPN gateway receives the web page and generates another HTTP response that contains the web page. The VPN gateway sends this HTTP response to the web browser through the tunnel. The web browser receives the web page and displays the web page to the user.
The web page may contain URLs that are associated with other resources in the VPN. For example, the web page may contain HTML links to other web pages within the VPN, or references to images that are stored within the VPN. Domain name servers outside of the VPN are unable to resolve such URLs. Assuming that no remedial action has been taken to compensate for this fact, if the user selects one of the links—by clicking on the link, for example—then the web browser indicates that the resource corresponding to the URL cannot be located. Similarly, the web browser will be unable to download an object, such as an image, at such a URL.
In order to compensate for this fact, the VPN gateway may perform operations on the web page prior to sending the web page to the web browser. More specifically, the VPN gateway may modify the URLs in the web page so that the URLs refer to the VPN gateway's URL. Each modified URL retains destination information that indicates the resource to which the URL originally referred, though. Modifying a URL in this manner is called “mangling” the URL. After the VPN gateway has mangled the URLs, the VPN gateway sends the web page, with the mangled URLs, to the web browser.
When the user selects a link that corresponds to a mangled URL, the web browser sends an HTTP request, through the tunnel, to the VPN gateway. The HTTP request indicates the destination information that was retained in the mangled URL. The VPN gateway receives the HTTP request and parses the destination information that is indicated therein. In a manner similar to that described above, the VPN gateway generates an HTTP proxy request that requests the web page at the original URL that the destination information indicates. The VPN gateway sends the HTTP proxy request, through the VPN, to the web server that is associated with the original URL.
As a result, the links in the web pages that the VPN gateway returns to the web browser still function as intended even though the resources to which the links refer might be within the VPN.
The process of mangling URLs is a lot of work for the VPN gateway to perform, though. The VPN gateway typically is a “bottleneck” in communications between processes executing within the VPN and processes executing outside of the VPN, so the VPN gateway's workload is often significant even if the URL mangling tasks are not considered. Because URL mangling is such a computationally expensive operation, it is often becomes necessary to implement the VPN gateway using specialized and expensive high-end computing machinery.
Thus, there is a need for a method or apparatus that can reduce the VPN gateway's workload so that the VPN gateway can be implemented using more general-purpose and less expensive computing machinery. More specifically, there is a need for a method or apparatus that can offload URL mangling from the VPN gateway.